User authentication system with self-signed certificate and identity verification with offline root certificate storage

ABSTRACT

In embodiments, a system and method is provided for authenticating a user to a verifying party computer over a network. A self-signed root certificate is generated and signed by a root private key on a user device. The user device generates an intermediate private key from a secure enclave on the user device. The intermediate private key is used to sign an intermediate certificate. The intermediate certificate is linked to the root certificate to form a certificate chain, the certificate chain including a user public key corresponding to a intermediate private key. The certificate chain is transmitted to the verifying party computer over the network. Next, user identification data is transmitted to the verifying party computer for linking with the certificate chain. Subsequently, the certificate chain can be transmitted to the verifying party computer to identify the user without the user identification data.

The present application claims the benefit of co-pending U.S.provisional applications Ser. No. 62/809,490, filed Feb. 22, 2019,entitled “Digital Signature System to Replace Passwords;” Ser. No.62/842,393, filed May 2, 2019, entitled “Digital Signature System toReplace Passwords;” Ser. No. 62/857,201, filed Jun. 4, 2019, entitled“User Authentication System with Self-Signed Certificate and IdentityVerification;” and Ser. No. 62/858,248, filed Jun. 6, 2019, entitled“User Authentication System with Self-Signed Certificate and IdentityVerification,” the disclosures of which are incorporated by referenceherein in their entirety.

BACKGROUND OF THE INVENTION

The present invention relates to replacing passwords with userpublic/private key certificates.

Currently, many websites and applications require a user login andpassword for access. Each new web-site requires a different user-nameand password. Password managers have been introduced that consolidatethem under just one password, and two factor authentication is sometimesused to improve security, but none of these approaches actuallyeliminates passwords or improves the user experience. Meanwhile,passwords are now the most common security breach in computer systems.Phishing expeditions continually deceive naive users into revealingtheir passwords, or criminals successfully guess those most commonlyused. The password concept is broken—password convenience is overriddenby the losses incurred.

TLS (Transport Layer Security) and its predecessor, SSL (Secure SocketsLayer) are Internet standards for two things: 1) services (servers)authenticating themselves to users (clients), and 2) encrypting messagesthat are decipherable by only the two parties in the connection. SSL wascreated by Netscape in 1995 and renamed to TLS when made into astandard.

Server Certificates. TLS uses X.509 certificates, each of which have adigital signatory. The signatory itself must also have a certificate,which has a second signatory. And that second signatory possesses acertificate with a third signatory, and so forth, leading to a chain ofcertificates. Starting with a root signatory, each certificate signs thenext until reaching the server's (end entity) certificate, which is thelast (“leaf”) certificate (the certificate used to access a websiteserver). A leaf certificate cannot be used to sign other certificates.According to the TLS protocol, this chain starts with a self-signedcertificate, which is from a single, universally-trusted root.

For simplicity and authentication convenience of services, this single,universally-trusted root has signed a select group of intermediateCertificate Authority (CA) certificates. Any CA in this select group cansign other certificates. The select group can vary in size, butmembership is determined by a consortium of browser vendors, OperatingSystems vendors, and Certificate Authorities called the CAB Forum.

Trust in a leaf server certificate is established by client-side TLSvalidating the signature of each certificate in the server's chain inreverse order, starting with the leaf. Encountering any trusted andvalidated certificate from this select group establishes trust in theleaf certificate. A second test challenges the server to prove itpossesses the correct private key for the leaf certificate. Success inboth of these tests is necessary for an authenticated, trustedconnection.

Mutual Authentication. TLS was symmetrically designed to allow bothservices and users to be authenticated using certificates, called mutualTLS. Client-certificates, like server-certificates, were expected to usean external, trusted, third-party signatory in their chain-of-trust thatis trusted to undertake the burden of establishing the user's actualidentity. It was recognized already in 1995 that there were problemswith this approach. First, few CAs would take the job of certifying theidentity of individuals needing certificates. Second, any given servicemight not trust any given CA to certify its users. Third,user-certificate CAs were an enormous additional bureaucracy. Hence,user-certificates were deemed to be not viable for normal users of theInternet, and from the outset, the common user-name/password was insteadadopted for user-authentication.

Currently, a Public Key Infrastructure (PKI) exists to allow users toverify the identity of a website, to make sure they are communicatingwith the correct entity. Public/Private key encryption is used for siteauthentication. A trusted, third-party Certificate Authority (CA) can beused to authenticate the identity of a website. In this process, theowner of a domain generates a public/private key pair. The public key ofthe website is wrapped in a Certificate Signing Request (CSR) along withother information, and it is signed with the private key. This CSR issubmitted to the CA for the creation of a Certificate. The trusted CAvalidates the ownership of the website's web address using whatevermeans determined by that CA to be necessary and sufficient. The CA thenuses the private key of an intermediate certificate, which was itselfsigned by a root certificate, to sign a Certificate for the website. Thesigned website certificate is referred to as a leaf certificate, whichidentifies the website but cannot be used to sign other certificates.The website leaf Certificate thus links to the trusted CA's own trustedcertificate, referred to as a root certificate, by way of theintermediate certificate that signed it, forming a chain ofcertificates. By trusting the CA's root certificate, any clientconnecting to the website can trust the leaf certificate presented bythe site as a valid identity of the website. Let's Encrypt® is the mostcommon root certificate CA today.

Consumer Device makers have incorporated Hardware Security Modules(HSMs) to store encryption keys, biometric data (for fingerprint andface recognition authentication). WebAuthn is a proposed standard by theW3C with input from the FIDO alliance, of which Google is a part, thatuses asymmetric, public/private encryption as a mechanism for secondauthentication factor. The private key can be stored internally in aconsumer device's HSM or in a special, separate key-storage device. Theproposed standard has multiple private keys, one per site, and requiresnew keys in the event of a lost device.

People have difficulties remembering passwords, so they often use thesame password everywhere. Moreover, passwords are cryptographically weakcredentials, as they can be guessed and are shared secrets. In the pastten years, mobile devices have caused a proliferation of Internetaccounts, which has stimulated demand for credential alternatives.

As detailed above, TLS has been limited by the need for third party CAs.Many companies offer alternative client credentialing systems that donot use TLS, including two-factor authentication, password managers, andmany other systems to augment the standard password. A few use TLS forclient-authentication, but paired with PKIs (Public Key Infrastructures)that operate a Certificate Authority (CA) to issue certificates tospecific individuals for use with the service. There are a number ofdescribed uses of self-signed certificates to authenticate a particulardevice, such as Published Application US 20130145151 (deviceauthentication), Published Application US 20120036364 (network device,such as a camera), and Published Application US 20190075099 (for virtualservers, with a broker).

Starting with the FIDO Alliance almost ten years ago up to today'sWebAuthn consortium of companies (notably, Google) and many othercompanies have devised alternatives to avoid the perceived deficienciesof TLS for client-authentication but still use TLS for serverauthentication and encrypted communications.

It would be desirable to have a password replacement that is easy touse, can be used across multiple devices, and allows recovery in theevent of a lost device.

BRIEF SUMMARY OF THE INVENTION

In embodiments, a system and method is provided for authenticating auser to a verifying party computer over a network. A self-signed rootcertificate is generated and signed by a root private key on a userdevice. The user device generates an intermediate private key from asecure enclave on the user device. The intermediate private key is usedto sign an intermediate certificate. The intermediate certificate islinked to the root certificate to form a certificate chain, thecertificate chain including a user public key corresponding to aintermediate private key. The certificate chain is transmitted to theverifying party computer over the network. Next, user identificationdata is transmitted to the verifying party computer for linking with thecertificate chain. Subsequently, the certificate chain can betransmitted to the verifying party computer to identify the user withoutthe user identification data.

In embodiments, a system and method replace multiple passwords with oneor more user certificates created and signed using public/private keyencryption under the supervision of the user. The system inverts thenormal certificate process, with the user supervising their ownCertificate Authority in concert with one or more Trusted Devices in theuser's possession. This system recognizes that, like a password system,the user does not need to be independently identified by a third party,but merely be able to present the same credential repeatedly to confirmthe same user accessed the website/application before.

In embodiments, the user generates their own public/private key pair,and the private key is used to sign a root certificate of the useracting as a Certificate Authority (CA), with the root private key storedoffline. An intermediate private key is generated on the secure enclave(e.g., HSM) of a user's device. The corresponding public key is thenincluded in a new Intermediate Certificate which is signed by the user'sroot private key, and references the User's Root Certificate through achain-of-trust. This chain is then used to verify the user to averifying party, with the verifying party able to follow the chain tofind the user's public key in the signed root certificate.

In embodiments, the user's root private key is stored not on the device,or in a HSM of the device, but rather externally. For example, the rootprivate key can be stored on a USB drive, printed as a QR code, orstored at a third party secure digital storage facility. Recovery fromloss of all devices is achieved by reading the root private key fromoffline-storage and re-generating the root certificate, and againsigning an intermediate certificate on a new device, therebyre-establishing a chain-of-trust that anchors on the user's rootcertificate.

In embodiments, the user can easily migrate trust to another device byproviding the root certificate and intermediate certificate as acertificate chain to a second device, which then adds a new intermediatecertificate to create a longer certificate chain with the same rootcertificate. In this process, the second device generates apublic/private key pair in its secure enclave and sends a certificatesigning request to the first device, which validates the request anduses it to extract the second device's public key, signing and returninga new intermediate certificate, with an updated chain to the seconddevice.

Any device in possession of an intermediate certificate and itscorresponding private key has the ability to sign new leaf certificatesto be used by other applications to authenticate into verifying partyservices.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating the creation of a Personal CredentialSystem and its installation on a newly Trusted Device according to anembodiment.

FIG. 2 is a diagram illustrating the process of credential migrationbetween two Mobile Devices according to an embodiment.

FIG. 3 is a diagram illustrating the process of Personal CredentialIssuance to Client Applications and the use of said credential toauthenticate against a Verifying Party according to an embodiment.

FIG. 4 is a diagram illustrating the process of credential recovery incase all Trusted Devices have been lost according to an embodiment.

FIG. 5 is a diagram illustrating the fields of a certificate accordingto an embodiment.

FIG. 6 is a diagram illustrating the process of authenticating a user toa verifying party through a browser instead of an app, such as throughthe proposed WebAuthn protocol, according to an embodiment.

FIG. 7 is a simplified block diagram of a representative computingsystem and client computing system usable to implement certainembodiments of the present invention.

FIG. 8 is a diagram illustrating the process of authenticating a user toa verifying party by way of cloud-rendezvous using a QR code, accordingto an embodiment.

DETAILED DESCRIPTION OF THE INVENTION Overview

The present invention leverages the availability of TLS on web servers.The present invention provides a way to use TLS with self-signedcertificates, eliminating the need for external, third-party CAs, andobviating the need for WebAuthn and other alternatives for clientauthentication. Alternately, other authentication protocols could beused, such as SAML and OpenID Connect, which could be used as deliverymechanisms for the Certificate Chains described herein.

Self-signed User Certificates. A self-signed certificate used with TLScannot alone authenticate a specific individual, but it does achieve anessential part of the authentication process: it guarantees possessionof the private key by the client presenting a certificate. When thechain validation process and challenge/response are successful, then bydefinition the client initiating the connection indisputably possessesthe private key and therefore owns the public-key certificate used tomake that connection. But a self-signature cannot establish identity, asanyone could otherwise claim to be someone else. However, theself-signed certificate will uniquely identify the same individual inthe database, just as a password does. No external CA and no password isneeded.

Cryptographic Credential. A service is connected via TLS using avalidated, self-signed certificate. The service then separately andindependently determines the connecting individual's actual identity,and creates a database record for that individual containing thecertificate. Then, when a self-signed certificate is subsequentlypresented in a connection and is affirmatively compared against thecertificate database entry of the individual, it securely identifies thespecific user.

The service essentially “completes” the certification that would havebeen done in an external, third-party CA. But because the user-identitywas determined after the certificate was issued, it cannot berepresented in the certificate itself. Rather, a second step ofcomparison against the self-signed certificate in the service's list ofusers is required to establish identity using the certificate.

First-time Process Example. When signing up for a service for the firsttime, in step 1) a client creates and presents to the service acertificate chain, anchored on a self-signed public key certificate,which is created from a private key that is kept secret. In step 2), theservice verifies all information it needs from the connection toestablish the identity of the specific individual, then creates anew-user database record that contains the certificate chain along withthat individual's identifying information.

Subsequent Log-in Example. Step 1) a client presents the samecertificate chain which the service validates, and performs achallenge/response to ensure certificate ownership (with TLS, this isdone automatically). Step 2) the service compares the presentedcertificate with certificates in the service's database. If both stepsare successful, the certificate belongs to and is a credentialidentifying the existing user and specific individual in the database.

Delete User Example. Either Certificate Invalidation or removal from thedatabase deletes a user.

The present invention turns the third-party CA chain-of-trust conceptupside down and inverts it to let the user self-sign a root CACertificate containing only their public key.

The server's chain-of-trust mechanism is fundamental to PKI operationsfor the Internet and has been well established for over twenty years,but user certificates present unique problems. Foremost is the scaleproblem of vastly more users than servers. Further, unlike stationaryservers that are maintained by professionals, users frequently ownmultiple devices and sometimes misplace or lose them.

In the existing process, getting a user-certificate requires theapplicant to create a Certificate Signing Request containinguser-specific information plus a public key, which is signed with theprivate key counterpart. The external trusted CA verifies the signatureof the CSR. Also, the CA verifies all user-specific information, usingwhatever means it considers sufficient. It then signs the certificate,attesting to its veracity. For everyday users, this is highly burdensomecompared to passwords, but even worse, it requires that the userre-establish themselves with the third-party CA even to add a newdevice. With the usual third-party CA, the user-specific information inthe certificate, such as email address, organization, etc., specificallyidentifies the owner.

The present invention eliminates the use of an external CA in order tovalidate users. In a traditional system, the CA attests to the publickey plus other information, such as email address, domain name, etcetera, belonging to a specific individual. In the present invention,everything but the public key is eliminated, so that the certificatecontains no user-specific information. Thus, the CA is verifying onlythe public key. But that assurance comes from the applicant via the CSR,signed by the applicant's private key. In this reduced case, then, theexternal CA serves no purpose, and it can be replaced by a root CAcertificate containing the applicant's public key signed by thecompanion private key. Logically, a private key in the possession of itsowner has to be accepted because it is indisputably true. We thuseliminate the external CA, and instead present credential in the form ofa chain-of-trust with the user's Personal Root Certificate at the end.

In the presented invention, the user uses devices containing HSMs tocreate user digital signatures without involving external CAs, whichmigrate readily to any number of other devices, easily recover from lostdevices, recover from catastrophic loss of all devices, and are easierto use than user-name/passwords.

The user-generated certificate of the present invention, like auser-name/password, is not intrinsically associated with anyone, and anyuse of it to identify an individual by a website must attach informationabout the individual, just as with a password login. For example, awebsite can ask for the user's name, address, email, phone number, taxID, social security number, credit card number, etc. The serviceestablishing trust in an individual puts the individual's information intheir database, but this needn't be in the certificate itself—thecertificate is just a signature. Unlike a password, however, it can't bestolen (it's “public”) and it can't be modified. It is just as easy touse, but far more secure.

With the additional information about the user eliminated from thecertificate, there is no problem trusting it—any self-signed certificateminimally attests that the public key it contains is the counterpart tothe private key used by the signer. Eliminating everything but thepublic key makes the certificate indisputably trustable—it only atteststo its public key, which is signed by its private key.

The user-certificate process according to the present invention is assimple as choosing a user-name and password while producing a unique“signature” that can't be hacked, and it allows the user to migratetrust to any new device.

Certificate Authorities have typically been utilized as external to theuser, with a user requesting a signed certificate by the authority inthe form of a Certificate Signing Request. Eliminating the third-partysigner enables the user to establish a signature, but not a specificpersonal identity. With the software tools to generate certificates andsign them, this capability is given to any user, allowing this solutionto be scaled. The user becomes their own CA.

The present invention also allows users to migrate their signature tonew devices with ease. Any user can generate any number of intermediatecertificates for separate devices, with the convention that the root CA,i.e. the last link in the chain of trust, identifies the owner with itspublic key—it's the anchor certificate in PKI parlance.

A Personal Root key pair and associated self-signed certificate aregenerated with an appropriate app on a first device, such as a mobilephone. Before exporting the Personal Root Private Key to cold storage,it is first used to sign an intermediate signing certificate of apublic/private key pair that is generated by the device's HSM. Becauseit is signed by the Personal Root Private Key, its chain-of-trustincludes the Personal Root Certificate. Most importantly, not only canit sign leaf certificates for any services to be authenticated on it,but also it can sign a new signing certificate for any new device.

All such devices therefore have similar capabilities, because all holdintermediate certificates that can sign for other intermediate and leafcertificates. The only differences between them is the number of linksleading to the Personal Root Certificate.

The user may have several options for offline storage. For example, itmight be printed out as a scannable QR code on a piece of paper, or onnon-volatile electronic storage, that might be kept in a safe-depositbox or other safe physical place. It might also be stored encrypted inan online key repository that has a rigorous process for re-establishingownership and decrypting it.

Because each device can operate the user's Personal CA, the chain forwhich has the same Personal Root Certificate, any device can replace anyother lost device by creating a new signing certificate for thereplacement device. Armed with the new signing certificate so issued,all applications re-installed on a new device would get new leafcertificates from the device's CA. Because the Personal Root Private Keyhas not changed and it contains the public key ID of the owner, theservice's authentication code needs no change; the new leaf certificate,with its chain-of-trust, is simply presented at authentication time. Theservice's authentication code checks the new chain leading to thePersonal Root Certificate, the Personal Root Public key of which will bean existing user.

This process of allowing a user to sign their own certificates leavesthe recovery and migration of the user's credentials completely withinthe user's control. The details of the implementation make this processof migration and recovery very simple for the user. Using the inventionis no more difficult for the user than retrieving a password manager andreinstalling it on a lost device. The system thus readily replacesuser-name/passwords with a parallel equivalent system that isincomparably more secure. The public key on the root certificate signedby the user's private key is the actual public root credential of theuser.

Definitions

A Client Application is a software module downloaded to and running on auser's device which is in possession of a leaf certificate signed by thePersonal Certificate Authority for the purpose of authenticating theuser when connecting to a Verifying Party (e.g., a web resource).

A Credential Recovery Service is an internet service that stores thePersonal Root Credential in secure storage vault on behalf of the user.The user uses separate credentials, or a combination of multiplecredentials to access the credential stored in the vault.

A Personal Certificate Chain is any certificate chain that validates toa Personal Root Certificate as a root certificate.

A Personal Certificate Authority is the virtual infrastructure comprisedof:

-   -   A Personal Root Certificate which is a certificate at the top of        the Personal Certificate Chain of a user. It has the capability        to sign other certificates, (i.e. operate its own Certificate        Authority). This certificate is trusted by the Verifying Party        to authenticate an individual user.    -   A Personal Root Credential which is the entity consisting of the        combination of the Personal Root Private Key and the Personal        Root Certificate. It should exist in the Trusted Devices only        during Personal Certificate Authority creation and recovery. At        all other times, only the Personal Root Certificate is used to        authenticate the user to the Verifying Party.    -   A Personal Root Private Key which is the private key used to        sign the Personal Root Certificate. Except at times of user        credential creation or restoration, this key is never accessed        or used by the system. It can be kept in cold storage, or stored        on a cloud-based Credential Recovery Service.

A Rendezvous Service is mechanism by which two devices (e.g., networkconnected) exchange information and agree on a shared secret used toestablish a channel of communication (e.g., via cloud service).

A Rendezvous Token is a large, random, time-gated shared secret whichtwo clients use to establish a channel of communication (e.g., directlyor via a central cloud service that will relay the messages betweenthem).

A Signing Application is a software module that runs on a user's devicethat contains the private keys and software necessary for the operationof the user's Personal Certificate Authority.

A Trusted Device is a user's personal computer device that contains aSigning Application initialized with an intermediate certificate, and aprivate key capable of signing a certificate on the user's PersonalCertificate Chain.

An Untrusted Device is a user's personal computer device that doesn'tyet contain a Personal Certificate Leaf and Personal Certificate Chain.

User Credentials are the presentation of a cryptographically-signedpayload, who's signing origins can be traced to possession of the user'sPersonal Root Certificate private key via a chain-of-trust validationmechanism.

A Verifying Party is any computer service that needs to authenticate auser's credential (e.g., in order to properly, safely and securelyoperate).

Introduction

The below description describes a mechanism for maintaining andpresenting User Credentials to Verifying Parties in the form of aPersonal Certificate Chain, validating to a Personal Root Certificate. APersonal Root Certificate is specified as the trust anchor of the UserCredentials.

The subject field of the Personal Root Certificate is irrelevant to thedescribed system. The Personal Root Public Key embedded in the PersonalRoot Certificate is the credential used to identify a given user.

The Personal Root Certificate is configured with the ability to signother certificates, allowing it to operate a Certificate Authority,signing intermediate certificates in the Personal Certificate Chain.

The Personal Root Certificate acts as the trust anchor of a PersonalCertificate Authority issuing certificates in the Personal CertificateChain of a specific user, signing certificates and other credentialsusing the user's Trusted Devices, coordinated with each other usingvarious Rendezvous Mechanisms. The private key of the Personal RootCertificate, called the Personal Root Private Key, is not stored on anyof the user's trusted devices. It is only used to restore the user'scredentials in the event of a total loss of all of the user's TrustedDevices. The Personal Root Private Key can be kept in cold storage, orin a Credential Recovery Service on the cloud. The intermediate privatekeys used for signing additional intermediate and leaf certificates inthe user's Personal Certificate Chain are created and stored within theHSMs of the Signing Application on the user's Trusted Devices. There isno need to export the intermediate private keys in order to operate thecredential system. New trusted devices can be added to the system byextending the user's Personal Credential Chain by one intermediatecertificate. The new intermediate certificate is signed by theIntermediate Private Key on any of the user's Trusted Devices via theRendezvous Mechanism.

Once initialized, the system can deliver any number of credentials thatutilize Personal Certificate Chains for user authentication. It can signleaf certificates for use in mutual TLS connections, or be embedded in aJSON Web Token for non-TLS challenge/response, or sign a challenge in aWebAuthn interaction. Because the Verifying Party uses the user'sPersonal Root Certificate to authenticate the user, the user can easilymigrate and recover lost credentials by signing new certificates ontheir Personal Certificate Chain, without direct involvement of theVerifying Party, simplifying the operational load on the Verifying Partyservers.

In an alternate embodiment, the Personal Root Certificate need not be aself-signed root certificate of the user as Certificate Authority. Itmay be an intermediate certificate on a larger chain, signed, orcross-signed, by any other Certificate Authority. Where on the chain thePersonal Root Certificate sits is less important than the fact that anyvalid chain that contains the certificate containing Personal RootPublic Key authenticates the user.

CA Operations

This section describes the initialization and operations that can beperformed on a user's Personal Certificate Authority.

Creating the Personal Certificate Authority

FIG. 1 is a diagram illustrating the creation of a Personal CredentialSystem and its installation on a newly Trusted Device according to anembodiment. A user device 110 (e.g., smartphone, tablet, computer, etc.)downloads or otherwise installs a signing application 112. The signingapplication includes the ability to create a private key 119 outside asecure enclave 116. Personal Private Key 119 is generated outside of theHSM of the device 110, and is used to self-sign the Personal RootCertificate 118, which is then used to sign an intermediate certificate120. The Personal Private Key is erased after being stored offline,outside the device 110, as described below.

This section describes the initial creation and set-up of a user's firstTrusted Device in their Personal Certificate Authority. This process isillustrated in FIG. 1. The user installs the Signing Application 112onto one of their devices 110 and begins the initialization process. TheSigning Application 112 generates a new Personal Root Private Key 119outside of device's hardware Secure Enclave 116 and uses it to createand sign the user's Personal Root Certificate 118. Together, thePersonal Root Private Key 119 and the Personal Root Certificate 118 arereferred to as the Personal Root Credential.

An Intermediate Private Key 114 is generated within the hardware SecureEnclave 116 of device 110 at the request of the Signing Application 112.The Intermediate Private Key 114 is generated by the Secure Enclave 116and its public key is used to create an Intermediate Certificate 120,which is signed by the Personal Root Private Key 119. The intermediateprivate key 114 can be used to sign other intermediate certificates orsign leaf certificates for credential delivery.

A Personal Root Credential 124 (consisting of Personal Root Certificate118 and Root Private Key 119) is presented in a format for cold storageor storage in a Credential Recovery Service. In one embodiment, thePersonal Root Credential 124 is imbedded in a QR code, bar code or isotherwise encoded, optionally encrypted and printed. Alternately,Personal Root Credential 124 is written to a USB dongle, a CD, oranother memory or physical device. In another embodiment, Personal RootCredential 124 is backed up at a third party trusted Credential RecoveryService 128. FIG. 1 shows the example of the entire Personal Rootcredential 124 being stored. The Credential Recovery Service 128 mayrequire a login and password, and/or other identifying information torecover the Personal Root Credential 124, such as a token of agovernment issued ID 130. This could be a driver's license number,social security number, etc. Once backed up, the Personal Root PrivateKey 119 is deleted from the Signing Application 112 and is not requestedagain unless it is required for Credential Recovery.

In an alternate embodiment, only the Root Private Key is storedexternally to the user device in cold storage. The Root Private Key canbe used to generate an exact copy of the original Personal RootCertificate. This can be done by knowing (in the Signing Program) andusing the same data for the other fields of the Personal RootCertificate. E.g., the same maximum expiration time, extensions, etc. Atype of key with randomness in its signature (e.g., Elliptical Curvekeys) is avoided, and instead, for example, RSA keys could be used.

Credential Migration

A problem with using certificates for user-authentication arises becauseof key protection systems on mobile devices—systems that do not allowexport of the private key. The private key is held in a HardwareSecurity Module (HSM), which is a separate processor that createsprivate keys, their public keys, and does all processing needed of them.This obviously presents a problem when a device is lost or a new one ispurchased, because the keys disappear when the device is erased. Thepresent invention provides a solution to mitigate this situation.

Private Keys, public keys, certificates, and so forth can still becreated without using a HSM. The first step in the solution is to createa self-signed root signing (CA) certificate without using the HSM.Second, create within the device's HSM a second private key for thedevice and sign its certificate, using the root private key, as an“intermediate signing (CA)” certificate. Finally, export the rootprivate key from the device for safe keeping, as it is the recovery key.

The intermediate signing device private key is a proxy for theoriginal—because it's a signing (CA) certificate, it too can signsubsequent certificates.

As before, any self-signed certificate can only assert ownership of itsroot private key, not an individual's identity. But all keys signed in achain ultimately point back to the self-signed root private key fortheir authority, so they inherit its ownership. Certificate chainscreated in this way are validated by following the chain from the lastcertificate to the root, validating signatures along the way.

All chains created with this root will be uniquely associated with anyindividual leaf certificate for a service. Once any leaf certificateestablishes itself to the satisfaction of the service it represents, theunique identity of a chain's root certificate is associated with thatspecific user's identity. In other words, the root's certificate becomesthe user ID for all services that use it.

TLS always uses the whole chain, not just the leaf certificate, inmaking a connection. Thus, after the chain is validated, the servicesimply gets the root certificate, or a representation of it, toassociate with the database record for any user. Other authenticationmechanisms could alternately be used, such as SAML, OIDC, WebAuthn, etc.

This process greatly simplifies propagating credentials to new devices.Any device can sign intermediate signing certificates for any otherdevice—that is, the user is in charge of giving credentials to any newdevice, which can sign for any service on that device. And if a deviceis lost, it can get new credentials from any existing device. If alldevices are lost, the root key can be recovered from a recovery service.

This section describes the method for bringing a new Trusted Device intothe user's Personal Certificate Authority, effectively migrating theuser's credential to the new device.

FIG. 2 is a diagram illustrating the process of credential migrationfrom an existing Trusted Device to a new User Device according to anembodiment. A trusted user device 210 (e.g., smartphone, tablet,computer, etc.) is assumed to already have the signing application 212installed and initialized with an intermediate certificate andintermediate private key. (This could be the device of FIG. 1, or asubsequent device). The signing application 224 on the new device 222includes the ability to create a private key 226 in a secure enclave228. Private key 226 is used to sign a certificate signing request (CSR)234, which is sent to Trusted Device 210 via a rendezvous method. TheCSR is used to construct Intermediate Certificate 230, which is signedby intermediate 1 private key 214 and sent back to Signing Application224, along with Intermediate Certificate 1 (220) and Personal RootCertificate 118 for installation into its secure enclave. Device 222 nowhas the ability to sign other intermediate and leaf certificates on theuser's Personal Certificate Authority.

The user may desire to provide the Personal Root Credential to a NewDevice 222, so that the user can issue Personal Certificate Chains fromeither device. First, the user installs (downloads) a SigningApplication 224 onto device 222. The Signing Application 224 creates anew intermediate 2 Private Key 226, from its Secure Enclave 228 (e.g.,HSM) and uses it to sign a Certificate Signing Request 234.

A connection is formed between the New Device 222 and Trusted Device 210(note that Trusted Device 210 does not need to be the original userdevice, but can be any Trusted Device). In one embodiment, theconnection uses a protocol implemented in gRPC (See https://grpc.io/ fordetails of the gRPC system) over standard TCP/IP. This is done using aRendezvous Mechanism used for discovery 232 as described in more detailbelow. Discovery can be initiated by the Signing Application, orseparately by the user with a standard communication mechanism on NewDevice 222.

The Signing Application 224 signs a Certificate Signing Request (CSR)234 using intermediate 2 private key 226. Using the available RendezvousMechanisms 232, the Client Application sends the CSR 234 to a SigningApplication 212 running on one of the user's Trusted Devices 210. TheSigning Application 212 signs the new CSR using its intermediate 1private key 214 and returns a Personal Certificate Chain 236 to theSigning Application 224 on New Device 222. The Signing Application 224installs the Personal Certificate Chain (118, 220, 230) into its SecureEnclave 228 and can now use it to present the user's credentials to aVerifying Party. New device 222 is now a Trusted Device. The resultingPersonal Certificate Chain 236 on the new Trusted Device 222 is longerby one intermediate certificate than the chain found on the SigningApplication 212 of the original Trusted Device 210.

Credential Presentation to Verifying Party

This section describes a method for the intermediate private key in aSigning Application on a Trusted Device to issue a leaf certificate forthe purposes of authenticating a user via a Personal Certificate Chain.

FIG. 3 is a diagram illustrating the process of Personal CredentialIssuance to Client Applications and the use of said credential toauthenticate against a Verifying Party according to an embodiment. Thetrusted device has the elements described above—a signing application112, a Personal Root Certificate 118, an intermediate certificate 120, asecure enclave 116 and an intermediate private key 114. In addition, aclient application (app) 308 is downloaded by the user from a particularwebsite or merchant, such as Verifying Party 310 on application server312.

Client application 308 includes a library provided to the verifyingparty (e.g., by the provider of the Signing Application) for compilingor linking into their client application. The library added to theClient Application 308 enables it to communicate with SigningApplication 112 once downloaded onto device 110. The Client Application308 creates a new leaf private key 320 in its secure enclave, and usesit to sign certificate signing request 324. Using available RendezvousMechanisms, the Client Application sends the CSR 324 to the SigningApplication (which can be Signing Application 112 on the same device, oranother Signing Application running on one of the user's other TrustedDevices). The Signing Application signs the new CSR using itsintermediate certificate key 114 and returns the leaf certificate 318and Personal Certificate Chain to the Client Application. The ClientApplication 308 installs the Personal Certificate Chain into its SecureEnclave 322 and can now use it to present the user's credentials toVerifying Party 310. In one embodiment, the Client Application is on adevice different than the Trusted Device.

Client Application 308 provides the Personal Certificate Chain of leafcertificate 318, Intermediate Certificate 120 and Personal RootCertificate 118 as a certificate chain to the Verifying Party 310 onApplication Server 312. This communication uses whatever protocol theVerifying Party requires. For example, such protocols can include clientTLS, WebAuthn (See https://www.w3.org/TR/webauthn/ for details of theWebAuthn protocol), Base64-encoded signed credential in the form of aJSON Web Token (See https://jwt.io/ for a description of the JSON WebToken), or signed responses in SAML format. When the certificate chainis presented to the Verifying Party 310, they validate up the chainuntil they reach the Personal Root Certificate, which identifies theuser to the Verifying Party system. Verifying Party 310 stores PersonalRoot Certificate 118 linked to a User Account 326. User Account 326 cancontain the data identifying the user, such as name, address, phonenumber, email, credit card, etc. Verifying Party would similarly storePersonal Root Certificates 328, 330 and other root certificates forother users, linked to their accounts.

There are multiple ways to communicate with a Verifying Party. Onceendowed with a leaf certificate, a Client Application can perform amutual TLS handshake with a server of the Verifying Party, or it canparticipate in a WebAuthn or similar exchange with the Verifying Party'sAPI as described in more detail below with respect to FIG. 6.

Credential Recovery

This section describes how the user can recover their credential if allTrusted Devices are lost. In this case, they will have to recover theircredential from their Personal Root Credential found in cold storage orin a Credential Recovery Service. FIG. 4 is a diagram illustrating theprocess of credential recovery in case all Trusted Devices have beenlost according to an embodiment. This is to some extent the reverse ofthe storage process of FIG. 1.

The user installs the Signing Application 412 onto a new, UntrustedDevice 410 and begins the Recovery process. The Signing Application 412prompts the user to present the backed-up Personal Root Credential 124,which is read but not stored in the application's secure enclave. AnIntermediate Private Key 420 is generated within the Secure Enclave 418of the Signing Application 412, and its corresponding public key is usedto create an Intermediate Certificate 416, which is signed by therecovered Personal Root Private Key 119.

The Personal Root Private Key 119 is deleted from the SigningApplication 412 and is not used again unless another Credential Recoveryis required. The intermediate private key 420 can now be used to signother intermediate certificates or sign leaf certificates for credentialdelivery. The trust relationship between the Signing Application 412 andall Verifying Parties is retained based on the fact that the SigningApplication continues to be able to sign certificates on a certificatechain that validates to the user's Personal Root Certificate. TheSigning Application can also extend the chain to other user devices withPersonal Root Certificate 118.

Personal Root Credential Storage

Credential recovery requires accessing the Personal Root Credential fromprotected storage. This section describes in more detail mechanisms forsecurely storing the Personal Root Credential offline, or in a protectedcloud service and how they may be used to recover the user's credentialas illustrated in FIG. 4.

Personal Root Private Key Cold Storage

Using this mechanism, the user's Personal Root Credential is storedoffline in a secure physical location by the user. When restoring auser's credential, the Signing Application is downloaded onto a newdevice and the copy of the Personal Root Credential is used to sign anintermediate certificate and establish a new Trusted Device. Possiblecold storage mechanisms include:

QR Code

On CA creation, a single-page document displaying a QR code containingthe Personal Root Credential is printed. This document is stored in aphysically secure location such as a locked filing cabinet or safe. Whenneeded for recovery, the user will scan this QR code with a newlyinstalled copy of the Signing Application. The recovered Personal RootCredential is used to sign a new intermediate certificate, which can beused henceforth to sign new intermediate and leaf certificates in thePersonal Certificate Chain.

USB Stick or Security Key

On CA creation, a USB stick is inserted into the device, where thePersonal Root Credential is stored in a standard location. This USBstick is stored in a physically secure location such as a locked filingcabinet or safe. When needed for recovery, the user will be prompted toinsert the USB stick or security key by a newly installed copy of theSigning Application, where it will read the Personal Root Credentialfrom the standard location and use it to sign a new intermediatecertificate, which will be used henceforth to sign new intermediate andleaf certificates in the Personal Certificate Chain.

Credential Recovery Service

Using this mechanism, the user has their Personal Root Credentialbacked-up to a cloud-based Credential Recovery Service in case they loseall of their Trusted Devices. When needed for recovery, the user enterstheir Credential Recovery Service credentials into a newly-installedSigning Application, which reads the Personal Root Credential and usesit to sign a new intermediate certificate, used henceforth to sign newintermediate and leaf certificates in the Personal Certificate Chain.

Rendezvous Mechanisms

The Personal Certificate Authority is running on multiple personaldevices that need to communicate with each other in order to signcertificates on behalf of Client Applications or unregistered SigningApplications. Additionally, the Verifying Party cloud services may needto request credential signings from one of the users Trusted Devices.This section describes mechanisms that may be used to rendezvouscommunication between these devices.

Direct Application Communication

Two devices can contact each other directly using industry-standarddiscovery methods. These include:

Bluetooth® LE

The Bluetooth® LE protocol provides for ad hoc device discovery anddirect communication between two different devices within closeproximity of each other.

ZeroConf Discovery

Known as Bonjour on Apple computers, a peer-to-peer connection may beestablished by two different applications registering their presence ona Local Area Network using the ZeroConf mechanism.

Android Peer Discovery

Android has a similar peer-to-peer discovery method to ZeroConf.

Any other method may be used as well.

Cloud-Based Rendezvous

Cloud-based rendezvous involves registering a secret, time-limitedrendezvous code that is then transferred to the other application, whichuses it to establish a connection on a cloud service to exchange databetween the two applications. The methods described below are used toexchange this secret. They typically don't have the capacity to exchangethe entire payload necessary for signing, or only provideuni-directional communication.

Application Scheme

One application can invoke another application on the same device bysending the operating system a small string in the form of a URL (on theorder of 1024 bytes). When invoked, an application will move to theforeground, read the URL and perform an action based on the URLcontents. The initiating application requests the rendezvous from thecloud service, which returns a rendezvous code. The initiatingapplication opens the receiving application using an Application Scheme.The receiving application opens a connection to the cloud service,providing the rendezvous code to complete the connection.

QR Code

The initiating application requests the rendezvous from the cloudservice, which returns a rendezvous code. The initiating applicationdisplays the rendezvous code as a QR code on its display, which thereceiving application scans with its camera. The receiving applicationopens a connection to the cloud service, providing the rendezvous codeto complete the connection.

Push Notification

The initiating application requests the rendezvous from the cloudservice, which returns a rendezvous code. The initiating applicationrequests that a push notification be sent to the receiving device. Thispush notification contains the rendezvous code. The receivingapplication opens a connection to the cloud service, providing therendezvous code to complete the connection.

Near Field Communication (NFC)

The initiating application requests the rendezvous from the cloudservice, which returns a rendezvous code. The initiating device sendsthe rendezvous code out via an NFC transmitter, which the nearbyreceiving application can read. The receiving application opens aconnection to the cloud service, providing the rendezvous code tocomplete the connection.

Certificate

FIG. 5 is a diagram illustrating the fields of an X.509 certificateaccording to an embodiment. Standard certificate fields are used in oneembodiment, but are populated differently. Certificate 510 contains aversion field 512, a certificate serial number 514 (unique for allcertificates in the Personal Certificate Authority), and a Certificatealgorithm identifier field 516 (describing how the certificate contentswere hashed, and the algorithm used to sign the hash). An issuer field518 would normally have a copy of the subject field of the certificatethat signed it. Here, it is left blank because the subject is leftblank, for the reasons set forth below.

Field 520 is a validity period, which would set forth the expirationdate of the certificate. This may be set to a very long period (e.g.,until the year 9999), so a user is not faced with the hassle of creatinga new certificate. A subject field 522 is left blank or one or more ofits fields are filled with a random or arbitrary numbers. In atraditional CA certificate, this would describe a company, with itslocation, phone number, address, email, etc. However, since the purposeof the user certificate in this application is to replace a passwordwith a public key, where it doesn't matter if it is intercepted, itwould be counterproductive to include other private, identifyinginformation of the user. Instead, such information is separately linkedin a user account at a verifying party as discussed above.

Field 524 contains the public key information, with an algorithmidentifier and a public-key value. This will be a different public keyfor each certificate. Optional and extension fields 526 can include avariety of data, including identifying whether the certificate is anintermediate certificate or a leaf certificate. Field 528 includes theCertification Authority's Digital Signature. In the present system, theCA is the user.

Authentication Through Browser, without an App

FIG. 6 is a diagram illustrating the process of authenticating a user toa verifying party through a browser instead of an app, such as throughthe proposed WebAuthn protocol, according to an embodiment. A user usesa browser 603 on a device 602 to communicate with a verifying party 601,such as a website for a merchant, bank, etc. The user's private key iskept in a Signing Application 604 or in a Signing Application 607 on anexternal device 606. In the proposed WebAuthn standard, the browser 603,upon the registration or the authorization ceremony, will seekauthenticators internally or externally. If device 602 is a trusteddevice, meaning it has a Signing Application with an intermediate key,and a signed intermediate certificate anchoring at the user's PersonalRoot Certificate, then the browser 603 on device 602 will forward asigning request to Signing Application 604 for authentication operationsvia an internal mechanism 605.

Another way this could be used in the embodiment is that external Device606 could register as an authenticator wirelessly to device 602 such asthrough Bluetooth LE or NFC, or external device 606 could be physicallyattached to device 602 via USB cable. In in any of these cases, trusteddevice 606 acts as an external authenticator to browser 603. Once theexternal connection 608 is established, the browser will forward signingrequests to Signing Application 607 for authentication operations. Inone embodiment, external device 606 is a USB memory, a disk drive orother memory device, or is a smartphone, Personal Digital Assistant(PDA), or any other electronic device.

Authentication Via Cloud Rendezvous

FIG. 8 is a diagram illustrating the process of authenticating a user toa verifying party by way of cloud-rendezvous using a QR code. VerifyingParty 801, using our supplied server libraries of the embodiment,establishes a connection 808 to a cloud-based Rendezvous Service 804 andrequests a user credential for use on its Client 803. Client 803 couldbe a web browser, or perhaps proprietary software on a kiosk or exerciseequipment. The Rendezvous Service 804 generates a rendezvous token 812and returns it to the Verifying Party 801, which renders it in the formof a QR code 810 and sends it via a connection 813 for display on itsclient 803. After presenting a scan page with QR code 810, the client803 and Verifying Party 801 maintain a persistent connection 813 tocomplete the authentication process. If the client is a web browser,then this can be performed via a Web Socket connection. If the client isan application, then the connection between Client 803 and VerifyingParty 801 must be kept open until after the user credential isdelivered.

The User, utilizing their user device 807, opens either VerifyingService 801's client application 805, or the Signing Application 806 ifno client application is installed on User Device 807. In either case,the user initializes a scan with the camera 811 on user device 807. Thescanning application reads the rendezvous token 812 from QR code 810 andestablishes a client-authenticated TLS connection 809 using the user'spersonal certificate chain including Personal Root Certificate 815 as acredential to the rendezvous service 804. This establishes that theconnecting entity is from an application that validates to the user'sPersonal Root Certificate 815. Once connection 809 is established theclient application 805 or the signing application 806 sends therendezvous token 812 to the cloud service 804 and closes the connection.The cloud service forwards the user's personal root certificate 815 tothe Verifying party 801 via connection 808 and closes the connection.

Verifying Party 801 generates a session token 814 and associates it withthe user's Private Root Certificate 815. It then sends a refresh commandto the client via connection 813. This command contains the generatedsession token that client 803 retains and presents as the usercredential for the duration of the session's validity. If the client isa web browser, this session token is stored as a cookie in the browser,if the client is an application, then the mechanism of session tokenpresentation is application-specific. This validity duration of thesession is specified by the Verifying Party 801 at the time of itscreation.

Computer Systems for Media Platform and Client System

Various operations described herein may be implemented on computersystems. FIG. 7 shows a simplified block diagram of a representativecomputing system 702 and client computing system 704 usable to implementcertain embodiments of the present invention. In various embodiments,computing system 702 or similar systems may implement the server orwebsite computing system or other verifying party, or any othercomputing system described herein or portions thereof. Client computingsystem 704 or similar systems may implement user devices such as asmartphone, tablet, computer, smart watch, or other devices.

Computing system 702 may be one of various types, including processorand memory, a handheld portable device (e.g., an iPhone® cellular phone,an iPad® computing tablet, a PDA), a wearable device (e.g., a GoogleGlass® head mounted display), a personal computer, a workstation, amainframe, a kiosk, a server rack, or any other data processing system.

Computing system 702 may include processing subsystem 710. Processingsubsystem 710 may communicate with a number of peripheral systems viabus subsystem 770. These peripheral systems may include I/O subsystem730, storage subsystem 768, and communications subsystem 740.

Bus subsystem 770 provides a mechanism for letting the variouscomponents and subsystems of server computing system 704 communicatewith each other as intended. Although bus subsystem 770 is shownschematically as a single bus, alternative embodiments of the bussubsystem may utilize multiple buses. Bus subsystem 770 may form a localarea network that supports communication in processing subsystem 710 andother components of server computing system 702. Bus subsystem 770 maybe implemented using various technologies including server racks, hubs,routers, etc. Bus subsystem 770 may be any of several types of busstructures including a memory bus or memory controller, a peripheralbus, and a local bus using any of a variety of bus architectures. Forexample, such architectures may include an Industry StandardArchitecture (ISA) bus, Micro Channel Architecture (MCA) bus, EnhancedISA (EISA) bus, Video Electronics Standards Association (VESA) localbus, and Peripheral Component Interconnect (PCI) bus, which may beimplemented as a Mezzanine bus manufactured to the IEEE P1386.1standard, and the like.

I/O subsystem 730 may include devices and mechanisms for inputtinginformation to computing system 702 and/or for outputting informationfrom or via computing system 702. In general, use of the term “inputdevice” is intended to include all possible types of devices andmechanisms for inputting information to computing system 702. Userinterface input devices may include, for example, a keyboard, pointingdevices such as a mouse or trackball, a touchpad or touch screenincorporated into a display, a scroll wheel, a click wheel, a dial, abutton, a switch, a keypad, audio input devices with voice commandrecognition systems, microphones, and other types of input devices. Userinterface input devices may also include motion sensing and/or gesturerecognition devices such as the Microsoft Kinect® motion sensor thatenables users to control and interact with an input device, theMicrosoft Xbox® 360 game controller, devices that provide an interfacefor receiving input using gestures and spoken commands. User interfaceinput devices may also include eye gesture recognition devices such asthe Google Glass® blink detector that detects eye activity (e.g.,“blinking” while taking pictures and/or making a menu selection) fromusers and transforms the eye gestures as input into an input device(e.g., Google Glass®). Additionally, user interface input devices mayinclude voice recognition sensing devices that enable users to interactwith voice recognition systems (e.g., Siri® navigator), through voicecommands.

Other examples of user interface input devices include, withoutlimitation, three dimensional (3D) mice, joysticks or pointing sticks,gamepads and graphic tablets, and audio/visual devices such as speakers,digital cameras, digital camcorders, portable media players, webcams,image scanners, fingerprint scanners, barcode reader 3D scanners, 3Dprinters, laser rangefinders, and eye gaze tracking devices.Additionally, user interface input devices may include, for example,medical imaging input devices such as computed tomography, magneticresonance imaging, position emission tomography, medical ultrasonographydevices. User interface input devices may also include, for example,audio input devices such as MIDI keyboards, digital musical instrumentsand the like.

User interface output devices may include a display subsystem, indicatorlights, or non-visual displays such as audio output devices, etc. Thedisplay subsystem may be a cathode ray tube (CRT), a flat-panel device,such as that using a liquid crystal display (LCD) or plasma display, aprojection device, a touch screen, and the like. In general, use of theterm “output device” is intended to include all possible types ofdevices and mechanisms for outputting information from computing system702 to a user or other computer. For example, user interface outputdevices may include, without limitation, a variety of display devicesthat visually convey text, graphics and audio/video information such asmonitors, printers, speakers, headphones, automotive navigation systems,plotters, voice output devices, and modems.

Processing subsystem 710 controls the operation of computing system 702and may comprise one or more processing units 712, 714, etc. Aprocessing unit may include one or more processors, including singlecore processor or multicore processors, one or more cores of processors,or combinations thereof. In some embodiments, processing subsystem 710may include one or more special purpose co-processors such as graphicsprocessors, digital signal processors (DSPs), or the like. In someembodiments, some or all of the processing units of processing subsystem710 may be implemented using customized circuits, such as applicationspecific integrated circuits (ASICs), or field programmable gate arrays(FPGAs). In some embodiments, such integrated circuits executeinstructions that are stored on the circuit itself. In otherembodiments, processing unit(s) may execute instructions stored in localstorage, e.g., local storage 722, 724. Any type of processors in anycombination may be included in processing unit(s) 712, 714.

In some embodiments, processing subsystem 710 may be implemented in amodular design that incorporates any number of modules (e.g., blades ina blade server implementation). Each module may include processingunit(s) and local storage. For example, processing subsystem 710 mayinclude processing unit 712 and corresponding local storage 722, andprocessing unit 714 and corresponding local storage 724.

Local storage 722, 724 may include volatile storage media (e.g.,conventional DRAM, SRAM, SDRAM, or the like) and/or nonvolatile storagemedia (e.g., magnetic or optical disk, flash memory, or the like).Storage media incorporated in local storage 722, 724 may be fixed,removable or upgradeable as desired. Local storage 722, 724 may bephysically or logically divided into various subunits such as a systemmemory, a ROM, and a permanent storage device. The system memory may bea read and write memory device or a volatile read andwrite memory, suchas dynamic random access memory. The system memory may store some or allof the instructions and data that processing unit(s) 712, 714 need atruntime. The ROM may store static data and instructions that are neededby processing unit(s) 712, 714. The permanent storage device may be anonvolatile read and write memory device that may store instructions anddata even when a module including one or more processing units 712, 714and local storage 722, 724 is powered down. The term “storage medium” asused herein includes any medium in which data may be stored indefinitely(subject to overwriting, electrical disturbance, power loss, or thelike) and does not include carrier waves and transitory electronicsignals propagating wirelessly or over wired connections.

In some embodiments, local storage 722, 724 may store one or moresoftware programs to be executed by processing unit(s) 712, 714, such asan operating system and/or programs implementing various serverfunctions such as functions of UPP system 102, or any other server(s)associated with UPP system 102. “Software” refers generally to sequencesof instructions that, when executed by processing unit(s) 712, 714 causecomputing system 702 (or portions thereof) to perform variousoperations, thus defining one or more specific machine implementationsthat execute and perform the operations of the software programs. Theinstructions may be stored as firmware residing in readonly memoryand/or program code stored in nonvolatile storage media that may be readinto volatile working memory for execution by processing unit(s) 712,714. In some embodiments the instructions may be stored by storagesubsystem 768 (e.g., computer readable storage media). In variousembodiments, the processing units may execute a variety of programs orcode instructions and may maintain multiple concurrently executingprograms or processes. At any given time, some or all of the programcode to be executed may be resident in local storage 722, 724 and/or instorage subsystem including potentially on one or more storage devices.Software may be implemented as a single program or a collection ofseparate programs or program modules that interact as desired. Fromlocal storage 722, 724 (or nonlocal storage described below), processingunit(s) 712, 714 may retrieve program instructions to execute and datato process in order to execute various operations described above.

Storage subsystem 768 provides a repository or data store for storinginformation that is used by computing system 702. Storage subsystem 768provides a tangible non-transitory computer-readable storage medium forstoring the basic programming and data constructs that provide thefunctionality of some embodiments. Software (programs, code modules,instructions) that when executed by processing subsystem 710 provide thefunctionality described above may be stored in storage subsystem 768.The software may be executed by one or more processing units ofprocessing subsystem 710. Storage subsystem 768 may also provide arepository for storing data used in accordance with the presentinvention.

Storage subsystem 768 may include one or more non-transitory memorydevices, including volatile and non-volatile memory devices. As shown inFIG. 7, storage subsystem 768 includes a system memory 760 and acomputer-readable storage media 752. System memory 760 may include anumber of memories including a volatile main RAM for storage ofinstructions and data during program execution and a non-volatile ROM orflash memory in which fixed instructions are stored. In someimplementations, a basic input/output system (BIOS), containing thebasic routines that help to transfer information between elements withincomputing system 702, such as during start-up, may typically be storedin the ROM. The RAM typically contains data and/or program modules thatare presently being operated and executed by processing subsystem 710.In some implementations, system memory 760 may include multipledifferent types of memory, such as static random access memory (SRAM) ordynamic random access memory (DRAM). Storage subsystem 768 may be basedon magnetic, optical, semiconductor, or other data storage media. Directattached storage, storage area networks, network attached storage, andthe like may be used. Any data stores or other collections of datadescribed herein as being produced, consumed, or maintained by a serviceor server may be stored in storage subsystem 768.

By way of example, and not limitation, as depicted in FIG. 7, systemmemory 760 may store application programs 762, which may include clientapplications, Web browsers, mid-tier applications, relational databasemanagement systems (RDBMS), etc., program data 764, and one or moreoperating systems 766. By way of example, an example operating systemsmay include various versions of Microsoft Windows®, Apple Macintosh®,and/or Linux operating systems, a variety of commercially-availableUNIX® or UNIX-like operating systems (including without limitation thevariety of GNU/Linux operating systems, the Google Chrome® OS, and thelike) and/or mobile operating systems such as iOS, Windows® Phone,Android® OS, BlackBerry® 10 OS, and Palm® OS operating systems.

Computer-readable storage media 752 may store programming and dataconstructs that provide the functionality of some embodiments. Software(programs, code modules, instructions) that when executed by processingsubsystem 710 a processor provide the functionality described above maybe stored in storage subsystem 768. By way of example, computer-readablestorage media 752 may include non-volatile memory such as a hard diskdrive, a magnetic disk drive, an optical disk drive such as a CD ROM,DVD, a Blu-Ray® disk, or other optical media. Computer-readable storagemedia 752 may include, but is not limited to, Zip® drives, flash memorycards, universal serial bus (USB) flash drives, secure digital (SD)cards, DVD disks, digital video tape, and the like. Computer-readablestorage media 752 may also include, solid-state drives (SSD) based onnon-volatile memory such as flash-memory based SSDs, enterprise flashdrives, solid state ROM, and the like, SSDs based on volatile memorysuch as solid state RAM, dynamic RAM, static RAM, DRAM-based SSDs,magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combinationof DRAM and flash memory based SSDs. Computer-readable media 752 mayprovide storage of computer-readable instructions, data structures,program modules, and other data for computing system 702.

In certain embodiments, storage subsystem 768 may also include acomputer-readable storage media reader 750 that may further be connectedto computer-readable storage media 752. Together and, optionally, incombination with system memory 760, computer-readable storage media 752may comprehensively represent remote, local, fixed, and/or removablestorage devices plus storage media for storing computer-readableinformation.

In certain embodiments, computing system 702 may provide support forexecuting one or more virtual machines. Computing system 702 may executea program such as a hypervisor for facilitating the configuring andmanaging of the virtual machines. Each virtual machine may be allocatedmemory, compute (e.g., processors, cores), I/O, and networkingresources. Each virtual machine typically runs its own operating system,which may be the same as or different from the operating systemsexecuted by other virtual machines executed by computing system 702.Accordingly, multiple operating systems may potentially be runconcurrently by computing system 702. Each virtual machine generallyruns independently of the other virtual machines.

Communication subsystem 740 provides an interface to other computersystems and networks. Communication subsystem 740 serves as an interfacefor receiving data from and transmitting data to other systems fromcomputing system 702. For example, communication subsystem 740 mayenable computing system 702 to establish a communication channel to oneor more client computing devices via the Internet for receiving andsending information from and to the client computing devices.

Communication subsystem 740 may support both wired and/or wirelesscommunication protocols. For example, in certain embodiments,communication subsystem 740 may include radio frequency (RF) transceivercomponents for accessing wireless voice and/or data networks (e.g.,using cellular telephone technology, advanced data network technology,such as 3G, 4G or EDGE (enhanced data rates for global evolution), WiFi(IEEE 802.11 family standards, or other mobile communicationtechnologies, or any combination thereof), global positioning system(GPS) receiver components, and/or other components. In some embodimentscommunication subsystem 740 may provide wired network connectivity(e.g., Ethernet) in addition to or instead of a wireless interface.

Communication subsystem 740 may receive and transmit data in variousforms. For example, in some embodiments, communication subsystem 740 mayreceive input communication in the form of structured and/orunstructured data feeds, event streams, event updates, and the like. Forexample, communication subsystem 740 may be configured to receive (orsend) data feeds in real-time from users of social media networks and/orother communication services such as Twitter® feeds, Facebook® updates,web feeds such as Rich Site Summary (RSS) feeds, and/or real-timeupdates from one or more third party information sources.

In certain embodiments, communication subsystem 740 may be configured toreceive data in the form of continuous data streams, which may includeevent streams of real-time events and/or event updates, that may becontinuous or unbounded in nature with no explicit end. Examples ofapplications that generate continuous data may include, for example,sensor data applications, financial tickers, network performancemeasuring tools (e.g. network monitoring and traffic managementapplications), clickstream analysis tools, automobile trafficmonitoring, and the like.

Communication subsystem 740 may also be configured to output thestructured and/or unstructured data feeds, event streams, event updates,and the like to one or more databases that may be in communication withone or more streaming data source computers coupled to computing system702.

Communication subsystem 740 may provide a communication interface 742,e.g., a WAN interface, which may provide data communication capabilitybetween the local area network (bus subsystem 770) and a larger network,such as the Internet. Conventional or other communications technologiesmay be used, including wired (e.g., Ethernet, IEEE 802.3 standards)and/or wireless technologies (e.g., WiFi, IEEE 802.11 standards).

Computing system 702 may operate in response to requests received viacommunication interface 742. Further, in some embodiments, communicationinterface 742 may connect computing systems 702 to each other, providingscalable systems capable of managing high volumes of activity.Conventional or other techniques for managing server systems and serverfarms (collections of server systems that cooperate) may be used,including dynamic resource allocation and reallocation.

Computing system 702 may interact with various user owned or useroperated devices via a wide area network such as the Internet. Anexample of a user operated device is shown in FIG. 7 as client computingsystem 702. Client computing system 704 may be implemented, for example,as a consumer device such as a smart phone, other mobile phone, tabletcomputer, wearable computing device (e.g., smart watch, eyeglasses),desktop computer, laptop computer, and so on.

For example, client computing system 704 may communicate with computingsystem 702 via communication interface 742. Client computing system 704may include conventional computer components such as processing unit(s)782, storage device 784, network interface 780, user input device 786,and user output device 788. Client computing system 704 also includes aHardware Security Module (HSM) 789. Client computing system 704 may be acomputing device implemented in a variety of form factors, such as adesktop computer, laptop computer, tablet computer, smart phone, othermobile computing device, wearable computing device, or the like.

Processing unit(s) 782 and storage device 784 may be similar toprocessing unit(s) 712, 714 and local storage 722, 724 described above.Suitable devices may be selected based on the demands to be placed onclient computing system 704; for example, client computing system 704may be implemented as a “thin” client with limited processing capabilityor as a high powered computing device. Client computing system 704 maybe provisioned with program code executable by processing unit(s) 782 toenable various interactions with computing system 702 of a messagemanagement service such as accessing messages, performing actions onmessages, and other interactions described above. Some client computingsystems 704 may also interact with a messaging service independently ofthe message management service.

Network interface 780 may provide a connection to a wide area network(e.g., the Internet) to which communication interface 740 of computingsystem 702 is also connected. In various embodiments, network interface780 may include a wired interface (e.g., Ethernet) and/or a wirelessinterface implementing various RF data communication standards such asWiFi, Bluetooth®, or cellular data network standards (e.g., 3G, 4G, LTE,etc.).

User input device 786 may include any device (or devices) via which auser may provide signals to client computing system 704; clientcomputing system 704 may interpret the signals as indicative ofparticular user requests or information. In various embodiments, userinput device 786 may include any or all of a keyboard, touch pad, touchscreen, mouse or other pointing device, scroll wheel, click wheel, dial,button, switch, keypad, microphone, and so on.

User output device 788 may include any device via which client computingsystem 704 may provide information to a user. For example, user outputdevice 788 may include a display to display images generated by ordelivered to client computing system 704. The display may incorporatevarious image generation technologies, e.g., a liquid crystal display(LCD), light emitting diode (LED) including organic light emittingdiodes (OLED), projection system, cathode ray tube (CRT), or the like,together with supporting electronics (e.g., digital to analog or analogto digital converters, signal processors, or the like). Some embodimentsmay include a device such as a touchscreen that function as both inputand output device. In some embodiments, other user output devices 788may be provided in addition to or instead of a display. Examples includeindicator lights, speakers, tactile “display” devices, printers, and soon.

Some embodiments include electronic components, such as microprocessors,storage and memory that store computer program instructions in acomputer readable storage medium. Many of the features described in thisspecification may be implemented as processes that are specified as aset of program instructions encoded on a computer readable storagemedium. When these program instructions are executed by one or moreprocessing units, they cause the processing unit(s) to perform variousoperation indicated in the program instructions. Examples of programinstructions or computer code include machine code, such as is producedby a compiler, and files including higherlevel code that are executed bya computer, an electronic component, or a microprocessor using aninterpreter. Through suitable programming, processing unit(s) 712, 714and 782 may provide various functionality for computing system 702 andclient computing system 704, including any of the functionalitydescribed herein as being performed by a server or client, or otherfunctionality associated with message management services.

It will be appreciated that computing system 702 and client computingsystem 704 are illustrative and that variations and modifications arepossible. Computer systems used in connection with embodiments of thepresent invention may have other capabilities not specifically describedhere. Further, while computing system 702 and client computing system704 are described with reference to particular blocks, it is to beunderstood that these blocks are defined for convenience of descriptionand are not intended to imply a particular physical arrangement ofcomponent parts. For instance, different blocks may be but need not belocated in the same facility, in the same server rack, or on the samemotherboard. Further, the blocks need not correspond to physicallydistinct components. Blocks may be configured to perform variousoperations, e.g., by programming a processor or providing appropriatecontrol circuitry, and various blocks might or might not bereconfigurable depending on how the initial configuration is obtained.Embodiments of the present invention may be realized in a variety ofapparatus including electronic devices implemented using any combinationof circuitry and software.

While the invention has been described with respect to specificembodiments, one skilled in the art will recognize that numerousmodifications are possible. Embodiments of the invention may be realizedusing a variety of computer systems and communication technologiesincluding but not limited to specific examples described herein.

Embodiments of the present invention may be realized using anycombination of dedicated components and/or programmable processorsand/or other programmable devices. The various processes describedherein may be implemented on the same processor or different processorsin any combination. Where components are described as being configuredto perform certain operations, such configuration may be accomplished,e.g., by designing electronic circuits to perform the operation, byprogramming programmable electronic circuits (such as microprocessors)to perform the operation, or any combination thereof. Further, while theembodiments described above may make reference to specific hardware andsoftware components, those skilled in the art will appreciate thatdifferent combinations of hardware and/or software components may alsobe used and that particular operations described as being implemented inhardware might also be implemented in software or vice versa.

Computer programs incorporating various features of the presentinvention may be encoded and stored on various computer readable storagemedia; suitable media include magnetic disk or tape, optical storagemedia such as compact disk (CD) or DVD (digital versatile disk), flashmemory, and other non-transitory media. Computer readable media encodedwith the program code may be packaged with a compatible electronicdevice, or the program code may be provided separately from electronicdevices (e.g., via Internet download or as a separately packagedcomputer readable storage medium).

Thus, although the invention has been described with respect to specificembodiments, it will be appreciated that the invention is intended tocover all modifications and equivalents within the scope of thefollowing claims.

What is claimed is:
 1. A method for authenticating a user to a verifyingparty computer over a network, comprising: generating a self-signed rootcertificate signed by a root private key on a user device; storing theroot private key externally to the user device; generating anintermediate private key from a secure enclave on the user device;signing an intermediate certificate with the root private key; storingthe intermediate private key in the secure enclave on the user device;linking the intermediate certificate to the root certificate by way ofsignature to form a certificate chain, the certificate chain including apublic key corresponding to the intermediate private key; transmittingthe certificate chain to the verifying party computer over the network;receiving, as an input to the user device, user identification data,including at least one of a user name, user address, user email, userphone number, user tax ID, user social security number and userfinancial account number; using a certificate chain as a credential totransmit user verification data to a verifying party computer; storingthe certificate chain in association with the user identification datain a database by the verifying party computer; receiving, at theverifying party computer, a subsequent communication from the userdevice including the certificate chain; and accessing the database bythe verifying party computer with the certificate chain to retrieve theuser identification data.
 2. The method of claim 1 further comprising:determining that the self-signed root certificate belongs to the userby: issuing a challenge question to the user device, by the verifyingparty computer, using the intermediate public key to encrypt thechallenge question; decrypting the challenge question by the user deviceusing the intermediate private key; and sending, by the user device, aresponse to the verifying computer challenge question, encrypted withthe intermediate private key.
 3. The method of claim 1 wherein theself-signed root certificate is an X.509 certificate suitable for usewith TLS.
 4. The method of claim 1 further comprising verifying, by theverifying computer, with TLS that the certificate chain belongs to theuser device.
 5. The method of claim 1 further comprising: storing, bythe user device, the intermediate private key in a signing applicationin a memory of the user device.
 6. The method of claim 1 furthercomprising: storing, by the user device, the root private key in anexternal electronic device; and recovering the root private key from theexternal electronic device.
 7. The method of claim 1, wherein the stepof storing the root private key externally to the user device furthercomprises encoding the root private key as a visual code and printingthe visual code, and further comprising: recovering the root private keyby scanning the visual code.
 8. The method of claim 7 wherein the visualcode is a QR code.
 9. The method of claim 1, wherein the step of storingthe root private key externally to the user device further comprisestransferring the root private key to an external memory device; andfurther comprising: recovering the root private key by connecting theexternal memory device to the user device.
 10. The method of claim 1,wherein the step of storing the root private key externally to the userdevice further comprises: transmitting the root private key to acloud-based credential recovery service server; and recovering the rootprivate key from the cloud-based credential recovery service using atleast one of a login, a password, or other user identifying information.11. A method for authenticating a user to a verifying party computerover a network, comprising: generating a self-signed root certificatesigned by a root private key on a user device; generating anintermediate private key from a secure enclave on the user device;signing an intermediate certificate with the root private key; linkingthe intermediate certificate to the root certificate to form acertificate chain, the certificate chain including a public keycorresponding to the intermediate private key; transmitting thecertificate chain to the verifying party computer over the network;transmitting user identification data to the verifying party computerfor linking with the certificate chain; and transmitting the certificatechain to the verifying party computer in a subsequent communication toidentify the user without the user identification data.
 12. The methodof claim 11 further comprising: determining that the self-signed rootcertificate belongs to the user by: issuing a challenge question to theuser device, by the verifying party computer, using the user public keyto encrypt the challenge question; decrypting the challenge question bythe user device using the intermediate private key; and sending, by theuser device, a response to the verifying computer challenge question,encrypted with the intermediate private key.
 13. The method of claim 11further comprising: storing, by the user device, the intermediateprivate key in a signing application in a memory of the user device. 14.The method of claim 11 further comprising: storing, by the user device,the root private key externally to the user device.
 15. The method ofclaim 14, wherein the step of storing the root private key externally tothe user device further comprises: encoding the root private key as avisual code and printing the visual code.
 16. A non-transitory computerreadable medium having stored thereon software instructions that, whenexecuted by a processor, cause the processor to generate control signalsfor authenticating a user to a verifying party computer over a network,by executing the steps comprising: generating a self-signed rootcertificate signed by a root private key on a user device; generating anintermediate private key from a secure enclave on the user device;signing an intermediate certificate with the root private key; linkingthe intermediate certificate to the root certificate to form acertificate chain, the certificate chain including a public keycorresponding to the intermediate private key; transmitting thecertificate chain to the verifying party computer over the network;transmitting user identification data to the verifying party computerfor linking with the certificate chain; and transmitting the certificatechain to the verifying party computer in a subsequent communication toidentify the user without the user identification data.
 17. Thenon-transitory computer readable medium of claim 16 wherein the softwareinstructions, when executed by a processor, further cause the processorto generate control signals to execute the steps comprising: determiningthat the self-signed root certificate belongs to the user by: issuing achallenge question to the user device, by the verifying party computer,using the user public key to encrypt the challenge question; decryptingthe challenge question by the user device using the intermediate privatekey; and sending, by the user device, a response to the verifyingcomputer challenge question, encrypted with the intermediate privatekey.
 18. The non-transitory computer readable medium of claim 16 whereinthe software instructions, when executed by a processor, further causethe processor to generate control signals to execute the stepscomprising: storing, by the user device, the intermediate private key ina signing application in a memory of the user device.
 19. Thenon-transitory computer readable medium of claim 16 wherein the softwareinstructions, when executed by a processor, further cause the processorto generate control signals to execute the steps comprising: storing, bythe user device, the root private key in an external electronic device.20. The non-transitory computer readable medium of claim 19 wherein thesoftware instructions, when executed by a processor, further cause theprocessor to generate control signals to execute the steps comprising:encoding the root private key as a visual code and printing the visualcode.